Apps run on iOS. All this time developing on mac and for naught, as apps don't run on macOS. /s maybe you can play around and port your app to the Mac It's.....already is a mac app 🤔 But ain't nobody going to be using any command-line arguments. FWIW, my app's primary mode of interaction is via command line arguments due to what it does and the audience it targets (scripted interactions on managed devices), hence why this issue is of particular interest to me. I don't want to discourage you. You are. I appreciate your response and willingness to spend time trying to understand my issue but your last reply offers nothing constructive and tries to dismiss what I'm seeing as irrelevant. I fully understand this is an edge case. By definition edge cases are not common, but that doesn't invalidate what I'm trying to achieve for my app. I thank you for your time but I think I have already used up the usefulness of this discussion space as clearly I'm developing for the wrong platform.

First of all, passing arguments to an app is very unusual. It is but not totally out of the ordinary. I'm porting that side of things to a dedicated cli tool but I'm also learning about xpc, notifications etc at the same time. I would like to be more "mac arsed" in my app development. Insert comment about tech debt here. That said, --args is a feature available in the open command and CommandLine.arguments is a property available to macOS apps. The expectation is that those should operate consistently. I'm also aware that there is a potential conflict with things like using -AppleLanguages to change the language an app is launched in so there is some pre-processing going on by the OS that is parsed before an app is launched fully but again, --args is available to be used, whatever macOS is doing should be able to handle that and just pass through arguments array into the app. Plus, you are running all this through the "open" tool. Does it behave the same if you directly launch the executable with your arguments? Exact same behaviour. using open or calling the executable directly with arguments has the exact same effect. I did some further testing though. I created a new macOS 15 VM, installed Xcode 16 and nothing else. Creating a new project and compiling the boilerplate SwiftUI app adding nothing else and I can re-create the behaviour: # three single arguments open ./demoapp.app --args --foo --bar --baz ./demoapp.app/Contents/MacOS/demoapp --foo --bar --baz # App window displays as expected # one single argument, one arg value pair open ./demoapp.app --args --foo --bar baz ./demoapp.app/Contents/MacOS/demoapp --foo --bar baz # The app window will not appear. and the same with the rest of the examples. TBC, in the second example, the app launches, but the main window does not appear until I click on the icon for it in the dock. Adding NSApp.activate(ignoringOtherApps: true) has no effect as if the app window doesn't exist. edit: just adding in that I'm using a SwiftUI app in my demo but the same behaviour appears if using AppKit lifecycle. My gut tells me it's something with how macOS 15 is pre-processing arguments, looking for whatever, and how Xcode 16 compiles those apps. apps compiled in Xcode 15 (macos 14) don't have any of these issues, but I don't know enough about the app lifecycle on macOS to dig deeper and understand what's going on. Ultimately the fix is I re-write how I accept/process arguments but I'm not quite there yet, hence I have a dev box stuck on macOS 14 for the time being.

weird - only reason I revisited it is I set up a new mac just this week from scratch and was experiencing the same problem, figuring it wasn't something specific to my old setup. Thanks for the reply though @Etresoft and confirming it's not an issue for you. If that's the case I might try installing just macOS and Xcode and nothing else and see if I can increment my way towards the issue. For context, my device is corporate owned so has MDM enrolment, AV, and other paraphernalia so perhaps it's a combination of something that's impacting how apps are being launched. I'll do some more testing.

This is still an issue in Xcode 16.3 and macOS 15.4.1. Also no activity on my feedback. Searching for similar cases on google returns this post as the first hit so I'm guessing I'm the only one with this issue :/. Unfortunately I can't move my compile workflow to macos 15/xcode 16 with the current code and re-factoring to use something else like swift argument parser is going to take me some time.

Did an “erase all contents and settings” which seemed to help but the issue returned. After some experimentation the following appears to work reliably: Put on and unlock the unit. Observe that pass through is working but now windows appear, no gestures work and you can’t summon the home screen. While still wearing the vision pro, place the lens cover on. You will get a warning about low light. Wait 2-3 seconds and remove the lens cover and dismiss the warning. Any windows that should have been showing should now re-appear.

still busted. resetting optic id and/or disabling optic unlock marginally helps. Leave the unit in standby long enough and it will need a reboot for anything to work. only thing I haven't tried is a complete device reset.

ok, just checking in to say that it might have been an issue with optic id. I turned off "unlock with optic id" and it seems to behave. I haven't tried resetting optic id yet. I did re-enable optic unlock and it worked once but then went back to not working. edit: re-setting optic id seems to have fixed it (fingers crossed)

following https://developer.apple.com/documentation/servicemanagement/updating_helper_executables_from_earlier_versions_of_macos and updated the plists to use the BundleProgram key but I still can't get it to operate. in fact now regular agents and daemons don't load. launchctl list shows a LastExitStatus of 19968. Trying to do this the apple way for Ventura and beyond but I'm not finding it intuitive. Need more coffee or sleep (or both)